home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / pidentd / pidentd-2.6.1 / doc / TAP.doc < prev    next >
Text File  |  1995-07-30  |  14KB  |  335 lines
  1. TAP-std working group                                       D. Bernstein
  2. RFC NNNN                                                              IR
  3.                                        June 1991, revised 17 August 1992
  4.  
  5.                       TAP
  6.  
  7.  
  8. Status of this Memo
  9.  
  10.    This memo provides information for the Internet community. It does
  11.    not specify an Internet standard. Distribution of this memo is
  12.    unlimited.
  13.  
  14.  
  15. 1. Introduction
  16.  
  17.    It is common for Internet hosts to associate relatively long-lived
  18.    information to each TCP connection, often (but not always) including
  19.    a ``username'' or ``owner name'' or some other information about the
  20.    entity using the connection. TAP announces the information associated
  21.    with a particular TCP connection to the host on the other end of the
  22.    connection. TAP may be used on any host which associates relatively
  23.    long-lived information to each connection.
  24.  
  25.  
  26. 2. Overview
  27.  
  28.    This is a connection-based application which runs over TCP. The TAP
  29.    server listens for TCP connections on port 113 (decimal). After a
  30.    connection is established, the server reads one line of data which
  31.    specifies the connection of interest. If that connection exists and
  32.    is associated with system-dependent information, the server sends
  33.    the information. Otherwise it sends an error line. After sending the
  34.    information or error line, the server closes its connection. After
  35.    reading the information or error line, the client closes the
  36.    connection.
  37.  
  38.    The server will give information about TCP connections between the
  39.    server's host and host H only to host H itself. The two hosts (i.e.,
  40.    IP addresses) involved are not transmitted explicitly by the
  41.    protocol; they are implicit in the connection made to the server.
  42.  
  43.  
  44. 3. Request format
  45.  
  46.    The server accepts simple text query requests of the form
  47.  
  48.       <localport> , <foreignport>
  49.  
  50.  
  51.  
  52. TAP-std working group                                           [Page 1]
  53.  
  54. RFC NNNN                         TAP                         August 1992
  55.  
  56.  
  57.    where <localport> is the TCP port on the server's host and
  58.    <foreignport> is the TCP port on the client's host. All numbers are
  59.    expressed in decimal without a sign, and all text is ASCII. If the
  60.    request is not in this format, the server may immediately drop the
  61.    connection.
  62.  
  63.    For example, say rose is connected to the standard TELNET port on
  64.    host tulip, through TCP ports 6191 on rose and 23 on tulip. (Note
  65.    that rose and tulip are simply names used in this document to
  66.    identify two IP-connected machines. They are not fully qualified
  67.    domain names.) tulip connects to the TAP server at port 113 on rose.
  68.    It sends this line:
  69.  
  70.       6191 , 23
  71.  
  72.    Here 6191 is the TCP port on the TAP server's host (rose) and 23 is
  73.    the TCP port on the TAP client's host (tulip). This uniquely
  74.    specifies the given TELNET connection.
  75.  
  76.    The precise format of the request line is as follows: <localport>,
  77.    followed by any amount of whitespace, followed by a comma and any
  78.    amount of whitespace, followed by <foreignport>, followed by carriage
  79.    return and line feed. Whitespace means space or tab; "any amount"
  80.    means zero or more, though a client should not print excessively many
  81.    spaces. The server should read until the line feed and respond
  82.    immediately. The client should not send anything after the line feed,
  83.    though future revisions of this specification may permit additional
  84.    data. The client should not add initial zeros to its decimal numbers,
  85.    but the server must accept such numbers. Future revisions of this
  86.    standard may assign additional meaning to decimals with a leading 0.
  87.  
  88.  
  89. 4. Response format
  90.  
  91.    The server sends a response line in one of these two formats:
  92.  
  93.       <localport> , <foreignport> : USERID : <systemtype> : <conn-info>
  94.    or
  95.       <localport> , <foreignport> : ERROR : <errortype>
  96.  
  97.    Here <localport> and <foreignport> are the same numbers as in the
  98.    query. (If the client uses initial zeros, the server may do so as
  99.    well, but otherwise it should not use initial zeros.) <systemtype> is
  100.    an operating system name for the server's host as described in
  101.    Assigned Numbers, RFC 1060 or its successors. <conn-info> is
  102.    system-dependent information associated to the connection.
  103.    <errortype> is text describing an error as outlined below.
  104.  
  105.  
  106.  
  107.  
  108. TAP-std working group                                           [Page 2]
  109.  
  110. RFC NNNN                         TAP                         August 1992
  111.  
  112.  
  113.    <systemtype> may also be OTHER to specify any other operating system
  114.    not yet listed in Assigned Numbers. Even if the server's system is
  115.    listed in Assigned Numbers, the server may use OTHER for any reason,
  116.    including operating system type privacy. Future revisions of this
  117.    document may permit further values of <systemtype>.
  118.  
  119.    <conn-info> is in some format defined by the system. This document
  120.    does not define the format or meaning of <conn-info>. Often
  121.    <conn-info> is in the same format as a system-dependent mailbox name,
  122.    which is typically in the same format as a system-dependent username,
  123.    but these equivalences are not required. <conn-info> could be
  124.    encrypted with a secret key; it could carry something other than
  125.    information about the entity using the connection. For the purposes
  126.    of this protocol, <conn-info> is an uninterpreted octet string. See
  127.    section 5 for further details.
  128.  
  129.    For example, some possible responses to the 6191 , 23 query might be
  130.    the following:
  131.  
  132.       6191 , 23 : USERID : UNIX : joe
  133.       6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a
  134.       6191 , 23 : USERID : OTHER : StJohns.DODCSC.a
  135.       6191 , 23 : USERID : TAC : MCSJ-MITMUL
  136.       6191 , 23 : USERID : UNIX : a6X#-Yp,3147,2910
  137.       6191,23     :USERID:OTHER:wewishyouamerrychristmasandahappynewyear
  138.       6191 , 23 : ERROR : NO-USER
  139.  
  140.    An ERROR line means that the server could not determine the
  141.    information associated to the TCP connection. <errortype> tells why.
  142.    <errortype> may be any of the following:
  143.  
  144.       INVALID-PORT
  145.  
  146.      <localport> or <foreignport> was improperly specified---out of
  147.      the range 0 to 65535, for example---or the request was
  148.      otherwise non-standard. In this case the server may drop the
  149.      connection without replying.
  150.  
  151.       NO-USER
  152.  
  153.          The connection specified by the port pair is not currently in
  154.          use.
  155.  
  156.       HIDDEN-USER
  157.  
  158.      The connection is in use, but the information associated to it
  159.      is explicitly hidden.
  160.  
  161.  
  162.  
  163.  
  164. TAP-std working group                                           [Page 3]
  165.  
  166. RFC NNNN                         TAP                         August 1992
  167.  
  168.  
  169.       UNKNOWN-ERROR
  170.  
  171.          Cannot determine the information associated to the connection,
  172.      for an unknown reason. The server may give this <errortype> in
  173.      any case and for any reason, including privacy, whether or not
  174.      another <errortype> applies.
  175.  
  176.    Future revisions of this document may allow other <errortype> values.
  177.    The server may also report an <errortype> beginning with the letter
  178.    X; all such <errortype>s are reserved for experimental or
  179.    non-standard use.
  180.  
  181.    The precise format of the response line is as follows: <localport>,
  182.    followed by any amount of whitespace, followed by a comma and any
  183.    amount of whitespace, followed by <foreignport>, followed by any
  184.    amount of whitespace, followed by a colon and any amount of
  185.    whitespace. In the USERID case, it is then followed by USERID and any
  186.    amount of whitespace, a colon and any amount of whitespace,
  187.    <systemtype> and any amount of whitespace, a colon and any amount of
  188.    whitespace, one or more characters giving <conn-info>, and finally
  189.    carriage return and line feed. In the ERROR case, it is followed by
  190.    ERROR and any amount of whitespace, a colon and any amount of
  191.    whitespace, one or more characters giving <errortype>, and finally
  192.    carriage return and line feed.
  193.  
  194.    Note that this format is ambiguous if <systemtype> contains colons or
  195.    whitespace. Assigned Numbers does not currently list any <systemtype>
  196.    with colons or whitespace, but if it ever does, the TAP server must
  197.    use OTHER for the <systemtype> on such a machine. The server should
  198.    also not use a <systemtype> containing carriage return or line feed.
  199.  
  200.    Similarly, if <conn-info> or <errortype> begins with whitespace or
  201.    contains carriage return-line feed, the response line format is
  202.    ambiguous. The server must never use <errortype> containing
  203.    whitespace, carriage return, or line feed, and future revisions of
  204.    this RFC will never provide for such an <errortype>. The server
  205.    cannot send <conn-info> beginning with whitespace or containing
  206.    carriage return-line feed; it should not send <conn-info> containing
  207.    whitespace, carriage return, or line feed. ERROR : UNKNOWN-ERROR is
  208.    preferable.
  209.  
  210.    Finally, <systemtype>, <conn-info>, and <errortype> cannot be empty
  211.    strings, and cannot contain ASCII NUL (character 0).
  212.    
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. TAP-std working group                                           [Page 4]
  221.  
  222. RFC NNNN                         TAP                         August 1992
  223.  
  224.  
  225.    Later revisions of this protocol specification may further restrict
  226.    the octets which may be transmitted. In light of this, servers
  227.    should, if possible, limit <conn-info> to at most ASCII codes 33
  228.    through 126. Clients should, however, be prepared to handle all
  229.    octets.
  230.  
  231.    Note that there is no limit on line lengths: in particular, on the
  232.    length of <conn-info>. The client may drop the connection at any
  233.    time to avoid overflow. The server should, if possible, place the
  234.    most useful information within the first 512 characters of
  235.    <conn-info>.
  236.  
  237.  
  238. 5. Applications and security
  239.  
  240.    A TAP server may place any information it wants into its responses to
  241.    a TAP query. This protocol does not assign any meaning to <conn-info>
  242.    beyond its intrinsic existence as an octet string. So, in most cases,
  243.    a TAP client will simply record the bytes of <conn-info> in some
  244.    manner for possible interpretation later by the server host. This is
  245.    primarily useful as a form of remote auditing: if the client host
  246.    judges that the TCP connection represents an accidental or malicious
  247.    malfunction on the part of the server host, then <conn-info> may
  248.    permit the server host's owner to track down the exact source of the
  249.    malfunction. So the information returned by TAP in this case is of
  250.    primary benefit to the host generating that information.
  251.  
  252.    The TAP client can do nothing more than this unless it has an
  253.    external reason to assign meaning to <conn-info> received from that
  254.    particular host. Beware that assigning <conn-info> an unjustified
  255.    meaning will in general lead to security holes. Do not use TAP for
  256.    access control without documenting the external knowledge you have
  257.    which ensures that your use of <conn-info> for access control is
  258.    justified. An attacker could subvert the security of a server host or
  259.    of TCP/IP; and any host could send any information it wants along a
  260.    TAP connection. Two dangers of weak methods of access control are
  261.    that they may permit access which should be denied, and that they may
  262.    deny access which should be permitted.
  263.  
  264.  
  265. 6. Notes
  266.  
  267.    This section is not part of the TAP description proper. It provides
  268.    historical information and pointers to further information.
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276. TAP-std working group                                           [Page 5]
  277.  
  278. RFC NNNN                         TAP                         August 1992
  279.  
  280.  
  281.    TAP is derived from the protocol defined in RFC 931 by Mike StJohns.
  282.    It was first implemented by this author in early 1990, then again in
  283.    February 1991, and distributed via the USENET network under the name
  284.    authd. Later in 1991 two more independent interoperable
  285.    implementations were distributed through the Internet. In 1992
  286.    another independent interoperable implementation was distributed.
  287.    TAP, as defined in this document, is the same as the authd protocol,
  288.    which has not changed since its first implementation in early 1990.
  289.  
  290.    This document is a cooperative effort of the TAP-std working group.
  291.    TAP-std is an ad-hoc group with the following charter: ``This group
  292.    is chartered to document the TAP protocol as used on TCP port 113
  293.    around the Internet. Its first goal is to publish as quickly as
  294.    possible an accurate, well-understood, complete TAP specification
  295.    which reflects the consensus of the community. Afterwards it will
  296.    keep track of TAP usage and produce further documents as necessary.
  297.    This group will not publish as a standard any TAP variation which has
  298.    not been tested on the Internet, though it will make all reasonable
  299.    allowances for future extensions.''
  300.  
  301.    At the time of publication of this document, you can join the
  302.    tap-std mailing list by sending a subscription request to
  303.    tap-std-request@kramden.acf.nyu.edu, or by connecting to TCP port
  304.    39311 on 128.122.142.2 and typing your username. There is also a
  305.    mailing list for people who want to use TAP to solve problems. To
  306.    join, send mail to rfc931-users-request@kramden.acf.nyu.edu.
  307.  
  308.    The author would like to thank Chris Davis, Peter Eriksson, and Dave
  309.    Borman for their helpful suggestions used in creating the TAP-std
  310.    base document. Thanks go to all the participants in the TAP-std
  311.    working group for their suggestions, comments, and criticism.
  312.  
  313.  
  314. Security Considerations
  315.  
  316.    Security issues are discussed in section 5.
  317.  
  318.  
  319. Author's Address
  320.  
  321.    Daniel J. Bernstein
  322.    5 Brewster Lane
  323.    Bellport, NY 11713
  324.  
  325.    Email:  brnstnd@nyu.edu
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332. TAP-std working group                                           [Page 6]
  333.  
  334.  
  335.